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0 Data processing system for utitizing a memory-mapped coprocessor within a limited address 
space. 



@ A data processing system is disclosed which 
permits the use of a memory mapped floating point 
coprocessor or other such peripheral, by a process 
^ which is unable to address the peripheral's resident 
^memory location but which Is able to address a 
specified location. Memory mapping means intercept 
^ attempted accesses by the process to the specified 
(O location and diverts the process's access instruction 
to cause it to access the corresponding mapped 
A address instead. An illustrative implementation is 
C7also described, namely the use of a Weitek 1167 
Q memory-mapped, floating point coprocessor by pro- 
cesses running in the "virtual mode" of an Intel 
g- 80386 CPU. 
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DATA PROCESSING SYSTEM FOR UTILIZING A MEMORY-MAPPED COPROCESSOR WITHIN A UMITED 

ADDRESS SPACE 



This invention relates to the use. by programs 
being executed by the connputer ftasks" or 
"processes") which are incapable of addressing a 
specified memory range, of a floating point 
coprocessor or other peripheral device residing at 
the specified memory range. The invention particu- 
larly relates to such use by processes running 
under the well-known MS-DOS operating system 
and its segmentation scheme for addressing mem- 
ory. (MS-DOS is a trademark of Microsoft Corpora- 
tion of Bellevue. Washington.) 

The background of the invention is illustrated 
by reference to an Intel 80386 ("386") micropro- 
cessor ("CPU"). The 386 CPU is described in 
publications by and available from Intel Corpora- 
tion, Santa Clara. California, including the "Intel 
80386 Hardware Reference Manual," Order No. 
231732-1. the "Intel 80386 Programmer's Refer- 
ence Manual." Order No. 230985-1. and the "Intel 
80386 System Software Writer's Guide," Order No. 
231499-1. to which reference is hereby made. 

As will be appreciated by those of ordinary skill 
in the art. computers have proliferated in recent 
years. One popular CPU series is the so-called 
Intel 86-series microprocessor family, including the 
8086. the 8088. the 80286 ("286"). and the afore- 
mentioned 386. 

Backward compatibility with earlier-model 
CPUs is frequently an important consideration in 
CPU design, especially when a large installed base 
of earlier-model CPUs exists. In the Intel 86-serles 
family, compatibility has required the later-model 
CPUs to be able to deal with the segmentation 
scheme for addressing memory locations used in 
the 8086 and 8088 architecture. That scheme 
formed a significant part of the design philosophy 
of MS-DOS and limits the memory-addressing ca- 
pability of processes running under MS-DOS. 

As those of ordinary skill will know, in that 
segmentation scheme, the address of any given 
memory location is expressed in two parts, the 
segment address and the offset within the specified 
segment. In the 8086/8088 architecture, the seg- 
ment address can be up to four hex digits, ranging 
from OOOOh to FFFFh. The microprocessor obtains 
the actual or absolute address by shifting the seg- 
ment address leftward by one nibble (i.e., one hex 
digit or four bits, equivalent to multiplying by 16) 
and adding the offset address. 

The resulting 20-bit number is large enough to 
specify up to a one-megabyte address, which is 
the address range of the 8088 and 8086 micropro- 
cessors (because those CPUs have 20 address 



lines). An address of FFFFFh, i.e.. one less than 
lOOOOOh, can be expressed in segmented notation 
as FFFF:OOOF. The segment portion, FFFFh. is 
shifted left one position (multiplied by 16) to yield 

5 FFFFOh. to which the offset OOOFh is added to 
yield the absolute address FFFFFh. 

The MS-DOS operating system was to a great 
extent tailored to the 8088/8086 CPUs* addressing 
scheme. The present commercially available ver- 

10 sions of MS-DOS express addresses in the seg- 
mented scheme just described. 

Applications programs running under MS-DOS 
can run on the 386 in the 386*s "real" mode. In 
real mode, the 386 behaves largely as if it were an 

15 8086 or 8088 running at the 386*s relatively high 
clock speed. 

Such use of the real mode by an applications 
program, however, means that the 386*s hardware 
resources may not be optimally utilized. For exam- 

20 pie. a Weltek 1167 floating point co-processor 
(Weitek Corporation. Sunnyvale. California) is de- 
signed to reside at physical base address 
COOOOOOOh in the 386 architecture, and to be 
mapped into 64K of memory at addresses 

25 COOOOOOOh through COOOFFFFh. 

Instructions and pointers to operands are 
passed back and forth between the 386 and the 
Weitek 1167 coprocessor along the 386 address 
lines: for example, a MOV instruction generated by 

30 the 386 which specifies a 32-bit address in the 
Weitek 1167*s mapped range causes the Weitek 
1167 to parse the address, to decode it into its 
component instructions and pointers to operands in 
accordance with a predetermined protocol, and to 

35 execute the instructions using the specified 
operands. Reference is made to the "Weitek 1167 
Floating Point Coprocessor" dated July. 1987. pub- 
lished by Weitek Corporation. 

Programs which utilize the conventional MS- 

40 DOS real mode segmented address scheme can- 
not make use of such a coprocessor because that 
address scheme prevents them from generating 
the required addresses. Such a coprocessor could 
conceivably be mapped into one or another sub- 

45 range of the one-megabyte range so that it would 
be usable by real- mode programs. However, most 
real-mode MS-DOS programs are designed to ex- 
pect other components (e.g.. video memory, ROM- 
BIOS, free memory, etc.) at specified subranges 

50 within the one-megabyte range in accordance with 
the industry standard. Consequently, real-mode 
software which could use such a coprocessor when 
mapped into the one-megabyte range might prove 
unable to run on industry-standard computers 
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which had other components within the mapped 
subrange. 

In accordance with the present invention, a 
data processing system is provided which permits 
the use of a memory mapped floating point 
coprocessor or other such peripheral, by a process 
which is unable to address the coprocessor's mem- 
ory location but which is* on the other hand, able to 
address a specified location. Memory mapping, 
means intercept attempted accesses by the pro- 
cess to the specified location and diverts the pro- 
cess's access instruction to cause it to access the 
corresponding mapped address instead. 

Figure 1 is a pictorial representation of a map- 
ping scheme for a Weitek 1167 coprocessor In 
accordance with the present invention. Figures 2, 3. 
and 4 are representations of memory allocations 
relating to an illustrative implementation of the in- 
vention. 

The invention described herein relates to an 
arbitrary large-memory computer running a 
restricted- and segmented-memory program as a 
process. For example, the invention is believed to 
be capable of implementation by those of ordinary 
sfcill on computers based on, e.g., the well-known 
Motorola 68020 CPU or the aforementioned Intel 
80386 CPU. 

The invention will frequently be implemented 
through the use of a memory management unit 
(MMU) computer program, a type of program 
which will be familiar to those of ordi nary skill, to 
map the coprocessor's resident address in physical 
memory, inaccessible by the process, into a speci- 
fied portion of the address range accessible by the 
process. Attempts by the process to write to or 
read from the specified address range are thus 
directed to the coprocessor's resident address in 
physical memory instead, enabling the coprocessor 
to respond to the process. 

Those of ordinary skill having the benefit of this 
disclosure will appreciate that the basic function of 
the MMU in this context Is to intercept any read or 
write instruction generated by the process that is 
directed to an address within the specified range, 
prior to the transmission of the address on the 
computer's address bus, and to cause the trans- 
mission instead of a mapped address correspond- 
ing to the address range of the coprocessor or 
other peripheral instead. 

Preferred implementation techniques for par- 
ticular embodiments will of course vary with the 
type of CPU, operating system, MMU. and other 
factors familiar to those of ordinary skill. Many 
implementations of the invention will be directed to 
permitting MS-DOS processes, running in the con- 
ventional one megabytes of logical address space, 
to utilize a floating point coprocessor residing in 
physical memory outside that logical address 



space. 

For example, the aforementioned Weitek 1167 
floating point coprocessor resides in 64K beginning 
at physical memory locations COOOOOOO, as noted 

5 above, which is outside the addressing capability of 
a conventional MS-DOS program. In implementa- 
tions directed to that coprocessor, it is preferred 
that the coprocessor be mapped into 60K of logical 
memory beginning at address lOOOOOh. As will be 

10 appreciated by those of ordinary skill having the 
benefit of this disclosure, MS-DOS processes can 
address that range using a base segment of 
FFFFh, while still leaving almost 4K (less 10h 
bytes) of such MS-DOS addressable space for 

15 other uses. The loss of 4K of addressable space to 
the Weitek coprocessor is not believed appreciably 
to impair the coprocessor's operation. It is believed 
that few MS-DOS programs make use of the mem- 
ory range above the one-megabyte upper memory 

20 limit of the 8088 and 8086 CPUs; thus, implemen- 
tation of the inverition at this address should not 
have an adverse effect on the operation of many 
such programs: 

It will be apparent to those of ordinary skill 

25 having the benefit of this disclosure that in such 
implementations, the MMU must be designed so 
that attempts by the MS-DOS process to address 
memory ranges above the one-megabyte limit are 
not "wrapped around" into low memory. The high- 

30 est address that can be specified in 20 bits (five 
hex digits) is the aforementioned FFFFFh address. 
Consequently, use of an offset of greater than 
OOOFh with an FFFFh segment results in an ab- 
solute address exceeding this range. For example. 

35 an offset of 001 Oh, when added to an FFFFh seg- 
ment that has been left-shifted, results in lOOOOOh. 
The 8088 and 8086 CPUs ignore all but the low 20 
bits (because they have only 20 address lines), 
meaning that an address of, e.g., FFFROOII is 

40 treated by those CPUs as an address of 
0000:0001. While some MS-DOS programs delib- 
erately utilize that characteristic of those CPUs, the 
MMU must be designed not to emulate it. 

On the 386. the invention may be implemented 

45 in connection with the Weitek 1167 coprocessor 
using an MMU running in the 386*s "virtual 86" 
mode to manage the 386's paging feature (see the 
Intel Hardware Reference Manual, above). 

As noted above, the MMU should be capable 

so of mapping 60K bytes of extended memory at 
which the Weitek coproces sor resides into a logi- 
cal address space beginning at lOOOOOh. A func- 
tional outline of one exemplar type of MMU 
(referred to here as XMMU) is described here for 

55 purposes of illustration. In this context, the chief 
function of the XMMU is to manage hardware and 
software interrupts, instruction emulation, and gen- 
eral system error handling. The XMMU is similar in 
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functionality to the kernel of a simple operating 
systenn. The XMMU may also be designed to emu- 
late the architectural features of a computer which 
is compatible with the "industry standard" 80286 
computer architecture, as reflected, for example, in 5 
the COMPAQ DESKPRO 286. 

The XMMU may employ a technique referred 
to herein as "Interrupt reflection" to simulate the 
action of a real-mode software or hardware inter- 
rupt for a task which is running In the virtual mode ;o 
of the 386 CPU. Interrupt reflection causes the 
result of a hardware or software Interrupt gen- 
erated in connection with a virtual-mode task, to be 
the same as with a real-mode task. Reference is 
made to the Intel publications cited above, 75 

Through Interrupt reflection, virtual-mode tasks 
can be made to operate substantially identically to 
real mode. This permits the proper operation of the 
system ROM Interrupt handlers, of real-mode op- 
erating system interrupt handlers (e.g., those asso- 20 
dated with MS-DOS), and real-mode applications 
which trap interrupts. 

On the 386 CPU, hardware interrupt reflection 
exemplifies the general technique of interrupt re- 
flection. Therefore, a description of a hardware 25 
interrupt reflection technique is provided here. An 
XMMU software interrupt reflection technique dif- 
fers slightly from its hardware intemjpt reflection 
and will be described hereafter. . 

In understanding interrupt reflection. It is useful 30 
to examine the difference between the effects of 
interrupts in virtual mode and in real mode. In real 
mode on the 386 CPU. for example, a hardware 
interrupt number 8 proceeds as follows. The pro- 
cessor suspends execution of the currently execut- 35 
ing task at the address specified by the current 
contents of the code segment (CS) register and the 
instruction pointer (IP) register. The processor 
pushes the current contents of the flags register, 
the CS. and the IP register onto the current stack. 4o 
as defined by the current stack segment (SS) and 
stack pointer (SP) registers. These values are 
pushed onto the stack in the order just described, 
as illustrated In Fig. 2. 

The 386 CPU then determines the beginning 45 
execution address for the interrupt number 8 inter- 
rupt handler routine via the interrupt 8 vector lo- 
cated in low memory at address 0000h:0020h (20h 
= 4 ' 8). Finally, the processor clears the interrupt 
flag (IF) and trace flag (TF) bits in the cun-ent flags so 
register and continues execution at the beginning 
address of the interrupt 8 interrupt handler. In 
short the processor in real mode saves the current 
flags and the CS and IP registers on the stack and 
dispatches the interrupt 8 handler with the IF and 55 
TF bits cleared. The processor remains in real 
mode throughout this process. 

Interrupts are handled somewhat differently in 



virtual mode. To continue with the 386 hardware 
interrupt example, such interrupts proceed similarly 
in that they save the current flags and the CS and 
IP registers on the stack and dispatch the interrupt 
handler with the IF and TF bits cleared. In virtual 
mode, however, the interrupt handler executes at 
Ring 0 of protected mode and the stack on which 
the flags and the CS and IP registers are saved is 
a special Ring 0 stack which is not determined by 
the SS:SP register combination of the virtual mode 
task. This stack is illustrated in Rg. 3. 

Furthermore, the beginning address of the in- 
terrupt handler is not determined by reference to 
the interrupt vector located at 0000:{int number ' 
4). but instead by an entry in the system's Interrupt 
Descriptor Table (IDT). The IDT contains an entry 
for each valid interrupt in the system. 

The IDT entries for valid interrupts point to the 
XMMU*S code for handling interrupts. Additionally, 
more virtual-mode task information than just flags, 
CS. and IP is placed on the ring 0 stack when the 
interrupt occurs. The virtual mode stack, as deter- 
mined by the virtual mode task's SS:SP at interrupt 
time, is not altered. 

Interrupt reflection entails manipulation of the 
ring-O and virtual-mode stacks to cause results like • 
a real mode interrupt action for the virtual task. The 
desired end result is virtual-mode execution of the 
interrupt handler determined by the interrupt vector 
at 0000h:(4 ' interrupt number), using the same 
stack contents and entry flags as would have ex- 
isted if the interrupt had occurred in real mode. 

To achieve this on a 386 CPU, for example, the 
XMMU's interrupt reflection portions may follow the 
following steps within the protected mode interrupt 
handler (i.e.. within the interrupt reflector). 

Step 1: The virtual mode stack segment (SS) 
and stack pointer (ESP) reside In the ring 0 stack. 
Decrement the virtual mode ESP value in the ring 0 
stack by 6 (3 words). 

Step 2: Construct a protected mode address 
(pointer) to this new virtual mode stack address 
(SS:ESP in the ring 0 stack). This address pointer 
for the modified SS.ESP is referred to herein as the 
VSP. 

Step 3: Take the low word of the EFLAGS 
from the ring 0 stack and place it in the virtual 
mode stack at VSP + 4. 

Step 4: Take the CS word from the ring 0 
stack and place it in the virtual mode stack at 
VSP + 2. 

Step 5: Take the low word of IP from the 
ring 0 stack and place it in the virtual mode stack 
at VSP + 0. 

Step 6: Determine the beginning address for 
the virtual-mode interrupt handler via the interrupt 
vector at 0000h:(41nterrupt number). 
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Step 7: Place the CS for the virtual mode 
interrupt handler's vector into the ring 0 stack in 
place of the CS saved for the interrupted virtual- 
mode task. 

Step 8: Place the IP for the virtual mode 
interrupt handler's vector into the ring 0 stack in 
place of the low word of EiP saved for the inter- 
rupted virtual mode task. Zero the high word of the 
EIP saved on the ring 0 stack. 

Step 9: Clear the IF and TF bits in the 
EFLAGS In the ring 0 stack. 

At this point in the 386 CPU illustration, the 
XMMU's protected mode interrupt handier ex- 
ecutes an IRETD instruction to return to virtual 
mode and execute the virtual mode interrupt han- 
dler. The ring 0 and virtual mode stacks should 
appear generally as illustrated in Rg. 4 when the 
IRETD begins execution. 

In summary, the 386 implementation of the 
XMMU'S interrupt reflection logic comprises the 
following general steps. The processor interrupts a 
virtual mode task, saves the state of the virtual 
mode task on the ring 0 stack, and begins execu- 
tion of the XMMU'S interrupt handler in ring 0 of 
protected mode. The XMMU'S Interrupt handler 
manipulates the virtual mode stack to simulate the 
action of a real mode interrupt. The XMMU modi- 
fies the ring 0 stack frame to contain the appro- 
priate entry conditions for the virtual mode interrupt 
handler (the interrupt handler which would have 
been executed in real mode). Then the XMMU 
executes an IRETD instruction and the processor 
returns to virtual mode and executes the virtual 
mode interrupt handler with the same entry con- 
ditions that would have existed in connection with a 
real mode interrupt. 

A slightly different technique may be used for 
reflecting software interrupts. In the XMMU, most 
software interrupts can be designed to generate 
general protection (GP) faults and thus to enter an 
XMMU protected mode GP fault handler (such as 
via IDT entry number ODh). This is in contrast to 
the software interrupts entering the XMMU via an 
interrupt handler described by the appropriate en- 
try in the IDT. 

When a software interrupt occurs via a GP 
fault, the microcode programming, of the 386 CPU 
causes an error code to be Inserted at the bottom 
of the ring 0 stack. To reflect a software interrupt 
which entered through the GP fault handler, the 
XMMU may remove the error code from the ring 0 
stack, determine the interrupt number to be re- 
flected by decoding the faulting interrupt instruc- 
tion, and proceed with the same logic used for the 
hardware interrupts. 

To decode the faulting instruction, the XMMU 
creates a pointer to the faulting instruction on the 



ring 0 stack via the virtual-mode task's CS.EIP 
registers. The XMMU decodes the instruction at 
this virtual-mode address to verify that it is a soft- 
ware interrupt instruction and to determine the in- 

5 terrupt number for this software interrupt. 

The XMMU causes most software Interrupts to 
enter the XMMU'S interrupt handling through the 
GP fault handler because of certain design char- 
acteristics of some computers based on the Intel 

10 '86 CPU family. The original design of 8088-based 
MS-DOS systems ignored Intel warnings which re- 
served certain IDT entries for future use. When the 
80286 processor was introduced. Intel had indeed 
used some of these IDT entries for processor ex- 

75 ceptions related to new instructions and to the 
protected mode. The result was conflicting usage 
of these IDT entries. For example, software inter- 
rupt 5 (INT 5) is used to instruct the ROM BIOS to 
print the current contents of the display screen. In 

20 the 80286 and the 80386, this interrupt number is 
generated by the processor when the limit ar- 
guments in a BOUND instruction are exceeded. 

The problem of overlapping software interrupts 
and CPU exceptions is solved in the XMMU by 

25 setting the Descriptor Privilege Level (DPL) of all 
interrupt gates in the IDT to 0. This causes the INT 
instruction to generate a GP fault. References to 
null (all zeroes) IDT entries cause GP faults. This 
allows unused entries to be filled with zeroes in- 

30 stead of being initialized with a pointer to a default 
handler. In addition, references to non-existent IDT 
entries (beyond the limit of the IDT) cause GP 
faults, so the IDT can be truncated after the last 
entry actually used. By forcing all software interrupt 

35 instructions through the GP fault handler, the IDT 
entry use conflict between CPU exceptions and 
software interrupts is removed. 

Potential conflicts of IDT usage also exist in the 
XMMU between hardware interrupts and CPU ex- 

40 ceptions. In the COMPAQ Deskpro 286. for exam- 
ple, the interrupt controllers are programmed such 
that the diskette controller generates an interrupt 
14. In the 80386, on the other hand, interrupt 14 is 
generated by the processor when a Page Fault 

45 exception occurs. 

The XMMU intemjpt handler must be "able to 
differentiate between these two conditions. It may 
do so by taking advantage of the fact that the 
microcode programming of the 386 CPU causes an 

50 error code to be placed onto the stack when a 
Page Fault is generated. Since the top of the ring 0 
stack is a known value (it is taken from the TSS 
when the transition from virtual mode to protected 
mode occurs), checking for the presence of the 

55 error code is simply a matter of measuring the 
depth of the stack. The stack is one word (the error 
code) deeper when the interrupt has been entered 
via processor exception than when it has been 
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entered via hardware interrupt. Other processor 
exception/hardware interrupt conflicts may be han- 
dled in the same manner. 

The XMMU must handle system errors which 
occur during virtual-mode execution. Although ail 
system errors encountered by the XMMU will nor- 
mally be signalled by CPU exceptions, some of 
these exceptions are not errors at all, some of 
these errors are handled by the XMMU, and some 
errors are sent to the appropriate virtual mode error 
handler. In general, if an exception is generated by 
execution in protected mode (by the XMMU code), 
the XMMU displays an XMMU Exception Error and 
halts the system. If an error is generated by a 
virtual mode task, the XMMU will cause the CPU 
exception to be reflected to the corresponding vir- 
tual mode exception handler. The two exceptions 
to this rule are the Invalid Opcode fault and the 
General Protection fault hand lers in the XMMU. If 
one of these two faults occurs in a virtual mode 
task the VMFault routine takes over. VMFauit de- 
codes the faulting instruction to differentiate be- 
tween actual errors and instruction trapping (such 
as I/O trapping and instruction emulation). The at- 
tached pseudocode (Appendix A) describes the 
error handling logic for the XMMU'S protected 
mode CPU interrupt/exception handlers. 

The VMFault routine dispatches GP and Invalid 
Opcode faults to specific handlers based on the 
CPU instruction which caused the fault. I/O instruc- 
tions go to the I/O trapping logic. Software inter- 
rupts go to the software interrupt emulation and 
reflection logic. The HLT. CLTS, and LOCK instruc- 
tions are emulated. The LGDT and LIDT instruc- 
tions generate privileged operation errors which 
allow the user to choose between rebooting the 
system and continuing the system in real mode 
with the XMMU turned off. The MOV r32,CR0, 
MOV CR0,r32. MOV r32.DRX. and MOV DRX,r32 
instructions are emulated. The MOV instructions 
to/from TRx, CR2, and CR3 generate privileged 
operation errors. The MOVS instruction is checked 
for a special case emulation. Ail other instructions 
are reflected to the virtual mode invalid opcode 
interrupt handler. 

As part of its instruction decoding the VMFault 
routine detects and properly handles segment, 
operand size, and address size overrides. The 
VMFault routine also detects software interrupts 
and reflects them to the appropriate virtual mode 
Interrupt handler. The VMFault routine watches for 
the INT 15h Move Block function described below 
and calls the XMMU Move Block emulation code 
when needed. 

Those of ordinary skill having the benefit of this 
disclosure will recognize that an MMU may be 
designed that includes more functions than those 
just described. The foregoing description of an 



illustrative XMMU is intended to outline the general 
functions of an MMU. 

MS-DOS software intended to access the 
Weitek 1167 should execute appropriate proce- 

5 dures to confirm that a 386 CPU is in use and that 
the Weitek coprocessor is present. One CPU-iden- 
tifying procedure is described in a copending U.S. 
patent application filed August 3. 1987, by William 
Caldwell Crosswy entitled "Method for Distinguish- 

10 ing Between an Intel 80386 and an Intel 80286 
CPU." assigned to the assignee of the present 
application. On the Compaq Deskpro 386, execu- 
tion of an INT 1 1 BIOS call (from the CPU's real 
mode) will return a 1 in bit 24 of register EAX if the 

75 coprocessor is present, and additionally will return 
a 1 in bit 23 if the coprocessor is addressable by 
real mode applications (zeros othen^^ise). The exact 
procedure used may of course vary with the BIOS 
interrupt handler and the EAX bit map used in the 

20 particular computer design. The MMU should put 
the 80386 into virtual mode and use memory pag- 
ing to map logical addresses lOOOOOh through 
lOEFFFh to physical address space located at 
COOOOOOO through COOOEFFFh. 

25 MS-DOS processes may then address the 
Weitek 1167 coprocessor by setting the appro- 
priate segment register (for example, DS) to 
FFFFh, adding an address offset of 001 Oh (to ac- 
cess base address lOOOOh). then executing MOV 

30 instructions that generate Weitek 1167 addresses 
between lOOOOh and lOEFFFh. The following ex- 
ample illustrates Weitek 1167 instruction encoding 
for MS-DOS processes operating in virtual mode: 
Coprocessor segment = FFFF:0000h 

35 Offset to address 1 0OOOh = 001 Oh 
Opcode = ADD.S = OOOOh 
Source of 1st operand = Rl - 0001 h 
Source of 2nd operand = R2 = 0008h 
Actual address generated (sum of above) = 

40 FFFF:00l9h 

The segmented address, written FFFF:00l9h. 
is equivalent to writing address 100009h. The 
operands for the example register-to-register 

45 Weitek 1167 ADD instruction reside in the 
coprocessor's registers R1 and R2. 

The operand for a coprocessor memory-to-reg- 
ister instruction would be loaded into the MOV 
instruction source register. Execution of a 

50 doubleword MOV instruction transfers the 32-bit 
operand to a designated 1 167 register. 

In the Intel 286 and 386 architectures, the Intel 
coprocessor exception interrupt, generated by the 
Intel 80287 and 80387 coprocessors, is normally 

55 connected to interrupt line IRQ13. Application pro- 
grams running as MS-DOS processes normally 
supply an NMI interrupt service routine for any 
enabled Intel coprocessor exceptions. The service 
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routine typically clears the Intel coprocessor excep- 
tion (if pending) and chains to the previously exist- 
ing NMI vector. Unresolved coprocessor exceptions 
can result in system errors. 

The Weitek 1167 coprocesor likewise gener- 
ates an IRQ13 interrupt when it encounters an 
enabled exception. Since the IRQIG interrupt line is 
nornr>ally dedicated to Intel coprocessors, this ar- 
rangement minimizes the possibility of interrupt 
conflicts with other types of hardware, but con- 
sequently, however, application programs running 
as MS-DOS processes using the Weitek coproces- 
sor must distinguish between Weitek and Intel 
coprocessor exceptions upon the occurrence of an 
IRQ13 Interrupt. This can be done by trapping INT 
75h and, upon the occurrence an IRQ13 interrupt, 
checking the Weitek coprocessor's Accumulated 
Exception byte. After resolving Weitek coprocessor 
exceptions (if present), the application program's 
interrupt handling routine for INT 75h should clear 
the coprocessor's Accumulated Exception byte and 
chain to the previously existing INT 75h vector. 
The previous INT 75h service routine will presum- 
ably clear the secondary interrupt controller and 
invoke the NMI handler for compatibility with 
8088/8086 CPU software and possible Intel 80387 
coprocessor exceptions. If any Weitek coprocessor 
exceptions are enabled, IRQ13 interrupts should be 
handled in this manner or system error messages 
could result. 

With the benefit of this disclosure, it will be 
appreciated by those of ordinary skill that this 
invention is believed to be capable of application in 
other situations. For example, the invention could 
be implemented using the 386 virtual mode in 
connection with other processes designed to run 
on and constrained by the addressing scheme of 
an 8086 or 8088 CPU, such as programs executing 
under the well-known CP/M 86 operating system 
by Digital Research Inc., instead of under MS-DOS. 

Accordingly, this description is to be construed 
as illustrative only and as for the purpose of teach- 
ing those skilled in the art the manner of candying 
out the invention. Various modifications and 
changes may be made without departing from the 
spirit and scope of the invention as set forth below 
in the claims. It is intended that the following 
claims be interpreted to embrace all such modifica- 
tions and changes. 



a memory-mapped peripheral device residing at a 
physical address range outside the addressing ca- 
pability of said process: and 
means for mapping the resident address range of 
5 said peripheral device into an address range ad- 
dressable by said process. 
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Claims 

1 . A data processing system comprising: 
addressable memory; ss 
a central processor executing a process capable of 
generating addresses to address some but not all 
of said addressable memory; 
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REAL MODE SS:SP AT BEGIN OF 
INTERRUPT HANDLER EXECUTION. 
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@ Data processing system for utilizing a memory-mapped coprocessor within a limited address 
space. 



0 A data processing system is disclosed which 
permits the use of a memory mapped floating point 
coprocessor or other such peripheral, by a process 
which is unable to address the peripheral's resident 
memory location but which is able to address a 
specified location. Memory mapping means intercept 
attempted accesses by the process to the specified 



location and diverts the process's access instruction 
to cause it to access the corresponding mapped 
address instead. An illustrative implementation is 
also described, namely the use of a Weitek 1167 
memory-mapped, floating point coprocessor by pro- 
cesses running in the "virtual mode" of an Intel 
80386 CPU. 
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